Hadoop上でのカラムナストレージ | Hadoop Advent Calendar 2016 #13
こんにちは、小澤です。 この記事はHadoop Advent Calendar 13日目のものとなります。
前回は独自言語でHadoop上の処理を記述するPigについて書かせていただきました。
今回はHadoop上で利用できるカラムナストレージの紹介をさせていただきたいと思います。
カラムナストレージとは
Hadoop上に保持しておくデータとして、ログデータなど独自のフォーマットを持つテキストデータやCSV,TSVといったデータを想像することが多いと思います。
特にCSVやTSVなどはデータの列方向の項目が決まっているためSQL on Hadoopのテーブル定義に利用されていたりもします。 構造が決まっているデータを分析に使いたい時に、項目の数は大量にあるが1回の分析で必要になる項目数はそれほど多くないという場面が多々あります。 このような時に、データを行単位ではなく列単位で保持しておくと便利です。
カラムナストレージを利用する利点
Hadoopでカラムナストレージを利用する際の利点についての多くはディスクIOの削減にあります。
データ分析のシーンにおいて、一番の特徴はテーブル構造のようなデータがある際に特定の列のみを取得するという場面が多くなります。特にWebシステムでよくあるような、特定の行での絞り込みではなく特定の列に含まれる行を日付など大きな単位で一括で取得するという場面が多々あります。
行単位でデータを保持していると必要な範囲のデータをすべて一括で取得した後、不要なカラムのデータは無視します。 必要な行数が少ない場合はインデックスなどによって効率的にデータを取得できるかもしれませんが、数千億行やあるいはそれ以上の件数も扱う可能性があるデータ分析の場合これはあまり効率的とは言えません。 そこでまとまった範囲のデータに対してSQLのSELECTなどで指定したカラムのみを取得することでディスクIOを削減できるのがカラムナストレージとなります。
また、カラムナストレージの場合、同じ型のデータが連続して並ぶため圧縮効率もよくなるという利点があり、これもまたディスクIOの削減に役立っています。
一例を挙げると、Webシステムの場合だと特定のユーザIDを条件としてそれに紐づくユーザの登録情報を一通り取得するといった操作はよくあると思います。これは1行のデータではあるが、全カラムを取得しているといった状態です。 一方でデータ分析として特定の日にアクセスした全ユーザのアクセス時間とアクセスページには関連があるかといった情報を取得する場合は行単位では大量になりますが、必要なカラムは2つのみです。
行志向か列志向かは利用シーンに応じて使い分けが必要なものなので、優劣があるというわけではありませんがHadoopの主な用途を考えた時には列志向のほうが適切である場面のほうが多いということです。
Hadoop上で使えるカラムナストレージ
Hadoop上で使えるといっても、Hadoopでデータを保持するレイヤであるHDFSはファイルシステムなので、どんなデータでも格納することができます。 実際には、利用するエコシステムなどでそのファイルをインプットやアウトプットのフォーマットとして利用可能かということになります。 このように考えた時に代表的なものとしてはParquetやORCが挙げられます。
どちらを使うにしても詳細な構造については詳しく知らなくては困るという場面はあまりないと思いますので、簡単にそれぞれの利点の説明として、詳しく知りたい方向けに詳細なドキュメントや論文へのリンクを掲載しておくことにします。
Parquet
ParquetはGoogleが発表したDremelと論文のオープソース実装になります。
特徴としてはネストした複雑なデータ構造に強いというものがあります。そのため、扱うデータが複雑な構造を持つような場面においてはこちらを利用したほうが処理速度の向上が見込めます。
Dremelの論文はDremel: Interactive Analysis of Web-Scale Datasetsというタイトルで論文が公開されています。
ORC
ORCはParquetとは別なカラムナストレージの実装となっています。
ネストしたデータ構造にはあまり強くありませんが、stripeと呼ばれる単位でmaxやminといったデータに関する情報を持っているため、それを利用すれば読み込む必要のある範囲をさらに絞り込めるため、ディスクIOをそこでも削減できるようになっています。
ORCに関してはもともとHiveの一機能であったため、Hiveのチケットになっていますが、Jiraにドキュメントが添付されています。
どちらを使うべきか
どちらのほうがより優れているかという点においては一概には言いがたいのが現状です。 得意なデータ構造や苦手なデータ構造があったり、Hiveのように特徴をフル活用したエコシステムがあったりするので状況次第となります。
終わりに
今回はカラムナストレージについて解説しました。
具体的な実現方法よりも、なぜ使ったほうがいいのかという点に重点をおいて解説させていただきましたがいかがだったでしょうか？
こういった普段はあまり意識する機会は少ないど、実はかなり効率に効く内容というのもたまには意識してみるといいのかもしれません。
明日はHadoop界隈で今最も人気のあるSparkがどのような構成で動いているを書かせていただく予定です。
ぜひ、お楽しみに！
